Add systemd integration via a template unit by obbardc · Pull Request #6 · brgl/gpiod-sysfs-proxy

obbardc · 2026-04-21T12:59:57Z

Add the example systemd service files from the OpenEmbedded recipe[0].
The files are licenced under the same licence as the upstream project.

Link[0]: https://git.openembedded.org/meta-openembedded/tree/meta-filesystems/dynamic-layers/meta-python/recipes-support/gpiod-sysfs-proxy/gpiod-sysfs-proxy
Fixes: #3

brgl · 2026-04-21T14:25:36Z

Should we install the files too if we ship them? And how about dropping the sysv init script? I added it to yocto because sysv was the default at the time but I consider dropping it with systemd becoming the default.

obbardc · 2026-04-21T16:52:40Z

Should we install the files too if we ship them? And how about dropping the sysv init script? I added it to yocto because sysv was the default at the time but I consider dropping it with systemd becoming the default.

Did that. I didn't check if pyproject actually installs all the files though.

I dropped the sysvinit script and set a default mountpoint of /sys/class/gpio as we can't do the templating really. I think we may need a different approach for the Yocto recipe? Maybe we could ship two service files or something.

brgl · 2026-04-22T07:02:08Z

Should we install the files too if we ship them? And how about dropping the sysv init script? I added it to yocto because sysv was the default at the time but I consider dropping it with systemd becoming the default.

Did that. I didn't check if pyproject actually installs all the files though.

That's a question actually. If you can't test it (for instance: modify the yocto recipe to use it) then I'm fine with shipping them as an example and not installing them.

obbardc · 2026-04-25T01:26:51Z

Should we install the files too if we ship them? And how about dropping the sysv init script? I added it to yocto because sysv was the default at the time but I consider dropping it with systemd becoming the default.

Did that. I didn't check if pyproject actually installs all the files though.

That's a question actually. If you can't test it (for instance: modify the yocto recipe to use it) then I'm fine with shipping them as an example and not installing them.

I think the services get installed properly.

I just checked this with:

docker run -it --rm -v $PWD:/mnt debian:unstable bash

apt update
apt install python3-pip pkgconf libfuse-dev build-essential

cd /mnt
python3 -m pip install \
  --break-system-packages \
  --force-reinstall \
  .

find /usr/local/lib/systemd/system/ | grep gpiod

it shows:

/usr/local/lib/systemd/system/gpiod-sysfs-proxy.service

and I think those files woukd go into /usr/lib/systemd/system if it was a Yocto/debian build...

brgl · 2026-04-27T08:57:30Z

+]
+"lib/systemd/system/sysinit.target.wants" = [
+  "share/sysinit.target.wants/run-gpio-sys.mount",
+  "share/sysinit.target.wants/sys-class.mount",


This installs these files unconditionally. In my meta-openembedded recipe I only do this if the user selected the - admittedly quite intrusive - sys-class-mount PACKAGECONFIG switch. Should we have a corresponding switch here as well?

This installs these files unconditionally. In my meta-openembedded recipe I only do this if the user selected the - admittedly quite intrusive - sys-class-mount PACKAGECONFIG switch. Should we have a corresponding switch here as well?

Not sure if we can have a switch here without a lot of fudging around - that's why I made the python package install the most useful default service by default.

Do we really need to support both paths? I don't know enough about this really, but I suspect it'd make sense to support one by default in distros like debian etc?

Perhaps it'd make sense to install using a default path and push users to README for information to use alternate paths? again, I am not entirely sure here, but surely for modern installs there is a sensibe default? :-)

TBH I never really considered this could be packaged in Debian. :) Is mounting an overlay over /sys/class something Debian would accept as the default? Sounds quite risky to me.

Seems fine to me, if you install this you kind of need it to work :-)

Alternatively in the python install we could install 2x systemd services (one for each path, or a template and 2x services extending the template) to a doc dir (e.g. not install them), then in yocto/debian we could install the script by default and have the services as as separate packages, and let users choose which package they want to install (and in yocto you can keep the same var, just install different services to the right place) ?

Or (for yocto) possibly two mutually-exclusive packages: gpiod-sysfs-proxy-systemd-overlay and gpiod-sysfs-proxy-systemd-tmp with the former installing the /sys/class overlay units?

exactly, and in this python installer i should put the service files into a documentation dir.

Need to figure out how to make the services extend another service so we don't duplicate code.

Would it be too much to ask to also update the yocto recipe if you're doing it? :)

@brgl I updated this PR based on the conversation above. I haven't tested the service files in yocto yet, as I said it's a bit obtuse for me to build the yocto recipe :-). Could you try the service and README instructions in the Yocto recipe please ?

BTW, I think this is the final blocking PR to getting this pushed into Debian. I'd like to do that soonish :-)

Provide systemd support for mounting the gpiod-sysfs-proxy compatibility filesystem. The package now installs a single template unit, gpiod-sysfs-proxy@.service, with an instance name of the systemd-escaped mountpoint (e.g. gpiod-sysfs-proxy@run-gpio.service). No instance is enabled by default so the admin opts into the mountpoint they want: systemctl enable --now gpiod-sysfs-proxy@run-gpio.service systemctl enable --now gpiod-sysfs-proxy@sys-class-gpio.service Exposing /sys/class/gpio on a kernel where the sysfs GPIO interface is disabled needs the missing 'gpio' directory overlaid onto /sys/class first. The run-gpio-sys.mount and sys-class.mount units handle that and an instance-specific drop-in pulls them in only for the sys-class-gpio instance. PartOf= ties their lifetime to that instance for clean teardown and ConditionPathExists=!/sys/class/gpio makes them no-ops when the directory already exists. Other instances never touch the overlay. Fixes: brgl#6 Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>

brgl

FWIW it works fine in yocto.

Provide systemd support for mounting the gpiod-sysfs-proxy compatibility filesystem. The package now installs a single template unit, gpiod-sysfs-proxy@.service, with an instance name of the systemd-escaped mountpoint (e.g. gpiod-sysfs-proxy@run-gpio.service). No instance is enabled by default so the admin opts into the mountpoint they want: systemctl enable --now gpiod-sysfs-proxy@run-gpio.service systemctl enable --now gpiod-sysfs-proxy@sys-class-gpio.service Exposing /sys/class/gpio on a kernel where the sysfs GPIO interface is disabled needs the missing 'gpio' directory overlaid onto /sys/class first. The run-gpio-sys.mount and sys-class.mount units handle that and an instance-specific drop-in pulls them in only for the sys-class-gpio instance. PartOf= ties their lifetime to that instance for clean teardown and ConditionPathExists=!/sys/class/gpio makes them no-ops when the directory already exists. Other instances never touch the overlay. Fixes: brgl#6 Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>

brgl reviewed Apr 27, 2026

View reviewed changes

obbardc force-pushed the wip/obbardc/add-systemd-service branch from eb4522e to 9629d3c Compare June 25, 2026 06:02

obbardc changed the title ~~Add example systemd service files~~ Add systemd integration via a template unit Jun 25, 2026

obbardc requested a review from brgl June 25, 2026 06:12

brgl requested changes Jun 25, 2026

View reviewed changes

Comment thread share/gpiod-sysfs-proxy@.service

Comment thread share/gpiod-sysfs-proxy@.service Outdated

obbardc force-pushed the wip/obbardc/add-systemd-service branch from 9629d3c to bfb4e7b Compare June 25, 2026 23:23

obbardc requested a review from brgl June 25, 2026 23:23

brgl merged commit 0d8e430 into brgl:main Jun 26, 2026

Conversation

obbardc commented Apr 21, 2026

Uh oh!

brgl commented Apr 21, 2026

Uh oh!

obbardc commented Apr 21, 2026

Uh oh!

brgl commented Apr 22, 2026

Uh oh!

obbardc commented Apr 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brgl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants